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AUTOMATIC GENERATION OF 
VERIFIABLE CUSTOMER CERTIFICATES 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] Not applicable. 

STATEMENT REGARDING FEDERALLY SPONSORED 
RESEARCH OR DEVELOPMENT 

[0002] Not applicable. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

[0003] The present invention relates generally to establishing a secure communication session 
between a client and a server. More particularly, the invention relates the automatic generation of 
verifiable certificates for use in confirming the identity of a server. 

Background of the Invention 

[0004] The hitemet has made the dissemination of information across long distances easy and 
inexpensive. Further, the Intemet has facilitated controlling one computer or computer system 
fi-om a remote location. These types of remote activities create a security concern. 
[0005] Suppose that a consumer wishes to conduct an on-line purchase of a product from a 
merchant. At some point in the transaction, the merchant will request the consumer to transmit 
confidential information, such as the consumer's name, address and, in particular, credit card 
number. It is possible for an unauthorized entity to intercept information transmitted between the 
server and client. This is generally called the ''man-in-the-middle attack" in which an unauthorized 
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entity makes itself appear to be the trae merchant to which the consumer beheves it is 
communicating. The consumer, believing it is in communication with the true merchant, sends 
confidential data to the man-in-the-middle. The man-in-the-middle forwards the information on to 
the true merchant, but retains a copy of the confidential data. As such, the confidentiality of the 
consumer's information is compromised and the consumer may be none the wiser. 
[0006] To remedy this and other types of security breaches, the "secure sockets layer'' ("SSL") 
protocol was created to permit the consumer to verify the authenticity of the merchant before 
transmitting the consumer's confidential data. SSL's objective is to verify the identity of parties 
involved in a secure transaction and ensure that data transmission is protected fi:om tampering or 
interception. The following is an overview of how SSL works. In this context and throughout this 
disclosure, the term "client" refers to the entity attempting to initiate a communication. The term 
"server" refers to the entity to which the chent communicates and the entity whose identity is 
verified by the chent. Typically, the server is the content provider while the client uses the services 
provided by the server. Li the above vernacular, the consumer is the client and the merchant is the 
server. 

[0007] The chent initiates communication with the server by providing a variety of important 
infomiation. The chent sends the current level of SSL support, a random number and the 
encryption option it supports. The random number will eventually be used to generate a key for 
secure transmission. The server responds by providing similar information and its signed digital 
certificate. The server will select the version of SSL that will be used for the remainder of the 
session, generate its own random number and also present the encryption options it supports. The 
signed digital certificate will be used by the chent to confirm the server's identity. 
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[00081 There are a number of tests that the signed certificate must pass to confirm the identity 
of the server. First, the chent checks to make sure that the server's certificate has not exph-ed. 
Second, the chent checks to see if the certificate authority ("CA") that issued the certificate is on 
the cUent's Ust of trusted CAs. The third step involves vaUdating the server's private key used to 
sign the server's certificate with the pubhc key on record with the CA. If the information in the 
CA certificate differs fi-om what is contained in the digital signature, the public key will not decode 
the digital signature key and the server will not be vaHdated. The final step involves verifying that 
the server's domain name listed on the server certificate matches the domain name of the server in 
question. This last step protects against the man-in-the-middle attack described above. 
[0009] Although SSL is generally a very effective security mechanism, it is not without its 
deficiencies. First, cost to a server entity to participate in this process is fairly substantial. Also, 
SSL generally requires special technical expertise on the part of the server entity to configure the 
server for SSL participation typically requiring a network administrator or equivalent. For some 
types of server entities, such as web sites for large organization (e.g., Amazon.com), these 
deficiencies may not be too severe. However, for other organizations, particularly those that are 
cost sensitive and/or do not have sufficient technical expertise in-house, these problems are 
particularly troubling and, in fact, may preclude entry into on-line commerce. 
[0010] The deficiencies of SSL are particularly problematic for computer equipment that is 
mass produced and used in the server-cUent context described above (i.e., a client verifies the 
authenticity of the server before transmitting information). The certificate provided by the server 
to the client typically includes the server's Intemet Protocol ("IP") address as well as its domain 
name (e.g., "www.mycompanyname.com"). Such equipment cannot be shipped from the factory 
with the certificates aheady stored on the equipment because the equipment will not be assigned IP 
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addresses and domain names until purchased, installed, and turned on and booted up by the user of 
the equipment. As noted above, many such purchasers are inconvenienced by having to create 
their own certificates and, in fact, may not possess sufficient technical expertise to create the 
certificates. Further, the organization may not have the financial resources to commit to 
conventional SSL verification. 

[0011] Accordingly, a solution to the aforementioned problem is needed. Such a solution 
should make it possible for cHents to verify the authenticity of servers when estabhshing a secure 
communications link without the cost and technical expertise overhead of the conventional SSL 
protocol. Despite the advantages such a system would provide, to date no such system is known to 
exist. 

BRIEF SUMMARY OF THE INVENTION 
[0012] The problems noted above are solved in large part by a verification technique in which 
a client verifies the signatures included in two different digital certificates provided by a server. 
One certificate is called a basic certificate ("B CERT") and is programmed into the server, or 
whatever device or system it is desired to verify. The B CERT includes various values that are 
signed with a secure private key, which may be, for example, the private key of the manufacturer 
of the server or subsystem within the server. The second certificate is called the local certificate 
("L CERT") and is derived fi:om and includes the B CERT. The L CERT also includes one or 
more server identify values (e.g., IP address, domain name) and is signed by a second private key 
that is preferably different than the private key used to sign the B CERT. The B CERT preferably 
is created at the factory and therefore present is in the server upon installation of the server. It 
should be xmderstood that the B CERT may be present on a circuit board installed in the server. 
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[0013] The L CERT is created after an IP address, domain name, etc. is assigned to the server. 
The LCERT is created automatically by the server upon boot up, during another type of 
configuring process or at another time. The L CERT preferably is signed by another trusted 
private key. 

[0014] hi order for a client to communicate with the server, the client must verify the 
authenticity of the server. This process includes successfully verifying both certificates using the 
appropriate pubUc keys. Because this verification technique includes basing one certificate on 
another certificate, a chain of trust is developed by which the server's identity can be verified 
remotely by a client. Further, the verification process does not require the use of conventional SSL 
techniques and the expense and technical expertise generally required to participate in the 
conventional SSL verification. 

[0015] These and other advantages will become apparent upon reviewing the following 
disclosures. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0016] For a detailed description of the preferred embodiments of the invention, reference will 
now be made to the accompanying drawings in which: 

[0017] Figure 1 shows a server and chent system embodying the preferred embodiment of the 
invention; 

[0018] Figure 2 shows the steps performed by the server to automatically generate a verifiable 
certificate; and 

[0019] Figure 3 shows the steps performed by a cUent to verify the server's certificate. 
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NOTATION AND NOMENCLATURE 
[0020] Certain tenns are used throughout the following description and claims to refer to 
particular system components. As one skilled in the art will appreciate, computer companies may 
refer to a component and sub-components by different names. This document does not intend to 
distinguish between components that differ in name but not function. In the foUowing discussion 
and in the claims, the terms "including" and "comprising" are used in an open-ended fashion, and 
thus should be interpreted to mean "including, but not Umited to. . .". Also, the term "couple" or 
"couples" is intended to mean either a direct or indirect electrical connection. Thus, if a first 
device couples to a second device, that connection may be through a direct electrical connection, or 
through an indirect electrical connection via other devices and connections. To the extent that any 
term is not specially defined in this specification, the intent is that the term is to be given its plain 
and ordinary meaning. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0021] Referring now to Figure 1, system 100 is shown constructed in accordance with a 
preferred embodiment of the invention. As shown, system 100 includes a server 102 and a cHent 
120 in communication with one another via a network connection 122. The network connection 
122 preferably comprises the Internet, but alternatively may comprise any type of communication 
link. The general function(s) performed by server 102 can be anything desired, such as hostmg 
web pages, controlling an organization's computer system, etc. The server 102 preferably is a 
server computer, collection of computers or an entire network of computers within an organization. 
The cUent 120, which includes at least a processor 122 coupled to memory 124, preferably 
comprises a computer that can perform, if desired, a variety of fimctions. One function, however, 
preferably is to communicate with sever 102. The purpose of the communication with the server 
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102 might be to retrieve status information regarding the operation of the server, configure or 
reconfigure the server, or conduct other types of actions. In so doing, the chent 120 may have to 
transmit various types of confidential information to the server 102 (e.g., passwords) or retrieve 
confidential information fi"om the server. Accordingly, it is beneficial to the operator of the chent 
system 120 to be able to verify the authenticity of the server 102 before engaging in a 
communication session with the server. Further, a plurality of clients 120 may couple to the 
server, each one independently verifying the authenticity of the server. It should be understood 
that in general the invention appUes to one device verifying the authenticity of another device even 
out of the server/cHent context. 

[0022] As shown, server 102 includes a processor 106 coupled to a memory 106. Other 
devices may be included in the server, but are not shown in Figure 1 for sake of simpUcity. Such 
other devices may include a keyboard, mouse, display, other types of input/output circuitry and 
devices, additional processors, additional memory, etc. The authentication process generally 
includes the use of various values stored in the server 102, Several of such values are shown in 
memory 106, The values include a basic certificate ("B CERT") 110, a local certificate 
C'L CERT") 112, an Intemet Protocol C'lP") address 114, and a domain name 116, The memory 
106 in which these values are stored may comprise non-volatile memory a hard drive, various 
types of read only memory, etc.), volatile memory (e.g., various types of random access memory) 
or a combination of volatile and non-volatile memory. In one embodiment of the invention, a 
circuit board may be installed into the server 102 that provides communication capabilities. Such a 
board (not specifically shown in Figure 1) may include a processor and memory on which the 
values shown in Figure 1 are stored. 
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[0023] In accordance with the preferred embodiment of the invention, two certificates are used 
to verify the authenticity of the server by the client. The B CERT preferably is programmed or 
otherwise loaded into the server during the manufacturing process. The B CERT preferably 
includes a public key associated with server, a private key to permit the subordinate L CERT to be 
signed by the B CERT, a serial number associated with the server, a uniqueness value (e.g., a 
random number) and a digital signature. Different or additional values may be included in the B 
CERT as desired. The pubUc key and serial number may be associated with the server or circuit 
board contained within the server. The serial number, which is not required, preferably is xmique 
to the server and distinguishes that server from all other servers. The serial number can be 
replaced within any alphanumeric, binary or other value or string that uniquely distinguishes the 
server from other devices. 

[0024] The digital signature preferably comprises a signed {ie., encrypted) hash of the values 
listed above. That is, the values Usted above are combined together in some suitable fashion and 
processed by a suitable hash function. The output value from the hash ftinction is then encrypted 
using a private key to create the signature. The private key used to sign the hash may be a private 
key associated with the manufacturer of the server or device or circuit board within or coupled to 
the server. In accordance with one embodiment of the invention, all servers 102 may include the 
same B CERT. As such, the B CERTs may not include a serial number unique to any one 
particular server. Alternatively, the servers 102 may include different B CERTs — different in 
terms of the serial numbers and/or private keys used to sign the hashes. 

[0025] Being signed by a secure private key, the B CERT represents a certificate that generally 
verifies the authenticity of the server hardware on which the certificate is stored. To provide 
further verification assurance, a second certificate — ^the L CERT 112 — ^is automatically created by 



54698.02/1662 39900 



-8- 



the server 102 using the B CERT 110. The L CERT 112 preferably includes one or more values 
that identify the server such as an hitemet Protocol ("IP") address and domain name after such 
values are assigned or otherwise provided to the server 102. The L CERT may also include other 
configuration information as desired. These values (the B CERT, IP address, domain name) are 
then processed by a hash function, which may be the same or different than the hash fiuiction used 
to create the B CERT, and signed by a private key. This private key preferably, although not 
necessarily, is different than the private key used to sign the B CERT. The private key used to sign 
the L CERT 1 12 preferably is associated with the server and generated in some suitable manner by 
an operator of the server or by software running on the server. The user should add their B CERT 
to the browser's trusted domain list. After this happens, subordinate certificates ("L CERTs") will 
be accepted by the browser without complaining. 

[0026] Figure 2 illustrates the process 200 by which the L CERT 1 12 is created. This process 
may be performed upon initial boot up of the server or any other subsequent boot sequence or at 
any other desired time such as when the server's IP address and/or domain name change. In steps 
202 and 204, the server 102 is configured to generate values identifying the identity and location of 
the server such as an IP address (202) and a domain name (204). Then, these identity/location 
values are combined together with the B CERT 110 and perhaps other values as noted above (step 
206). In step 208 these values are hashed and in step 210, the resultmg hashed value is encrypted 
using the server's private key. 

[00271 Once the server 102 creates its L CERT 112, cUent devices 120 can then estabUsh a 
communication with the server using the B CERT 110 and L CERT 112 to verify the server's 
authenticity. Figure 3 shows one suitable embodiment of this process, hi this process, both 
certificates— the B CERT 110 and L CERT 112— may be verified. The process 300 in Figure 3 
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includes steps 302-330. When client 120 wishes to establish a communication session with the 
server 102, the client first requests the L CERT 1 12 from the server in step 302. Then, in step 304, 
the cUent retrieves the pubhc key associated with the server. As is well known, pubhc and private 
keys are typically generated as a corresponding pair. Thus, the pubhc key retrieved in step 304 is 
the pubhc key that corresponds to the private key that was used to sign the L CERT. This pubhc 
key may previously have been stored in the client, provided to the cUent by the server as part of the 
certificate or in a separate communication from the server or other device. 
[00281 Once retrieved, the public key is used to decrypt the digital signature portion of the 
L CERT (step 306). Then, in step 308, the unencrypted portion of the L CERT is hashed by the 
client 120 using the same hash algorithm used to create the hash for the L CERT in the first place. 
If the L CERT is authentic, the unencrypted signature from step 306 should match the hash 
computed in step 308. Accordingly, in step 310, the hash from step 308 is compared to the 
decrypted signature from step 306. If these values do not match, then the L CERT is detennined to 
be mvalid in step 3 12 and an appropriate action is taken in step 3 14. Suitable actions could include 
simply termmating the attempt to initiate a communication session between the cUent and server, 
reporting or broadcasting the failed verification as a potential security breach to other devices or 
administrators coupled to the server 102 and chent 112, etc. 

[0029] If, however, the two hashes regardmg the L CERT match in step 310, the local 
certificate is determined to be valid and the B CERT 110 is transmitted by the server to the chent 
preferably at the chent's request (step 316). Then, in step 318, the chent computes a hash of the 
encrypted portion of the B CERT. The hash function used in step 318 preferably is the same hash 
function used to generate the B CERT. In step 320, a pubhc key is retrieved that is associated with 
the private key that was used to sign the B CERT. This pubhc key may previously have been 
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stored in the client, provided to the dient by the server as part of the certificate or in a separate 
commiinication fi-om the servo: or other device. Once retrieved, this pubhc key is used in step 322 
to decrypt the digital signature portion of L CERT 112. 

[00301 The hashes are compared in step 324 and if tiiere is a mismatch, the B CERT 110 is 
determined to be invalid (326) and an appropriate action is taken in step 328. This action may 
include terminating the attempt to initiate a communication session between the cUent and server, 
reporting or broadcasting tiie failed verification as a potential security breach to other devices or 
administrators coupled to the server 102 and chent 112, etc. As such, the action taken in step 328 
to a failed B CERT verification may the same as the action taken in step 314 to a failed L CERT 
verification. Alternatively, the actions taken response to failed L CERT and B CERT verifications 
may be different. If, however, the hashes match m step 324, then in step 330, the B CERT is 
considered authentic and the communication session between the client and the server is permitted 
to continue. 

[0031] It should be understood that the order of many of the steps in Figures 2 and 3 can be 
changed from tibiat shown. For example, the process 300 of Figure 3 can include the chent 
requesting both the B CERT and L CERT certificates 110, 112 before verifymg either certificate. 
That is, the chent need not wait to request and receive the B CERT until flxe L CERT is 
successfiilly verified. 

[0032] hi this manner, the server is able to automatically generate a verifiable certificate that 
provides the chent reasonable assurance of authenticity. The certificate ("L CERT") is based on 
another certificate ("B CERT") and is signed by a private key pertaining to the server. The 
B CERT, in turn, is signed by a tiiisted authority, such as the manufacturer of the server. This 
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process avoids the need to use conventional Certificate Authority ("CA") and expend the 
substantial financial and technical resources to participate in conventional SSL verification. 
[0033] As explained above, if desired the B CERT 110 may include a serial number unique to 
the server in which the B CERT is stored. This serial number, which would make each B CERT 
different fix)m other B CERTs in other servers, is usefiil to provide additional verification. 
Specifically, by including a server-specific piece of information or value in the B CERT fiirther 
assurance is provided regarding the server's authenticity. 

[0034] The above discussion is meant to be illustrative of the principles and various 
embodiments of the present invention. Numerous variations and modifications will become 
apparent to those skilled in the art once the above disclosure is fiilly appreciated. It is intended that 
the following claims be interpreted to embrace all such variations and modifications. 
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